A tunnel has to be transferred when a mobile terminal which is using the relevant tunnel moves from the coverage area of the first controlling node into that of the second. This move results in an RAU (Routing Area Update), in the course of which data relating to the PDP context of the terminal is passed from the first controlling node to the second controlling node. This data is transmitted in the form of messages as in the GTP protocol (GPRS Tunnel Protocol). Messages in the GTP protocol are used inter alia for setting up and clearing PDP contexts and for passing on PDP contexts in the case of routing area updates. For details relating to the GTP protocol, reference should be made to the specification document 3G TS 23.060 Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS); Service Description; Stage 2 (Release 1999), for example in Version V3.3.0 dated April 2000 from the 3GPP (3rd Generation Partnership Project, 3GPP.org).
Data transmitted between the two controlling nodes makes it possible for the second controlling node to receive a contact for a gateway node and to use this to create the required complete information about the context, in order to allow it then to switch the GTP tunnel so that the service for the terminal can be continued without any interruption.
Two versions of the GTP protocol have been standardized to date, firstly the GTP Version 0, also referred to as Release 98 or 97, in GSM 09.60; secondly GTP Version 1, also referred to as Release 99, in the already mentioned publication TS 23.060. The standardization in Version 1 demands that nodes of the Version 1 type are intended to be able to interact with those of the Version 0 type, and that the GTP tunnels are operated using the respectively highest possible version.
In order that a receiving node can identify the GTP version which was used to produce a received message, the headers in each of the messages each include an identifier which allows association with the respective version. Messages which have been produced using Version 1 cannot be interpreted by nodes which are operating on the basis of Version 0 or even older standardizations. A node of the Version 1 type must therefore be able, depending on the GTP version which a node to which it is sending messages is using, to produce these messages either in accordance with Version 1 or Version 0.
One major difference between Version 0 and Version 1 of the GTP protocol is the method which is used to allocate a message to the tunnel which has been set up or to a PDP context. So-called tunnel identifiers, TIDs for short, are used for this purpose in Version 0, and are transmitted as part of the message, and are composed of the IMSI (International Mobile Subscriber Identity) and the NSAPI (Network Layer Service Access Point Identifier). IMSI is the worldwide unique identification number of a subscriber; NSAPI references one of a number of PDP contexts which may be associated with the subscriber. Since the tunnel identifier has a length of 12 bytes and is therefore quite cumbersome, so-called flow labels with a length of 2 bytes are additionally used instead of it, allowing rapid association of messages with a context. However, the flow labels are not necessarily allocated uniquely, since they have a value range of only about 65,000, and considerably more contexts can be set up for each node.
The flow labels are in each case allocated on activation of a GTP tunnel. Each node involved in a tunnel in this case signals to the opposing node the flow label with which it wishes to receive subsequent messages on this tunnel or, and this is completely equivalent, for this PDP context. In the first message which is sent in the course of setting up a tunnel from a controlling node to a gateway node (Create PDP Context Request), the flow label is set to 0 because the gateway node cannot yet allocate a flow label, and the tunnel identifier is transmitted. All subsequent messages in this tunnel must be sent using the flow label allocated by the gateway node. To be precise, two flow labels are allocated in each case, one for signaling and one for data. However, only the flow label for signaling will be considered in the following text.
In GTP Version 1, so-called TEIDs (Tunnel Endpoint Identifiers) are allocated, which have the same function as the flow labels, but have a length of 4 bytes. The TEIDs are thus not compatible with Version 0 flow labels, but they can be allocated uniquely. The tunnel identifier which is known from Version 0 is no longer included in Version 1 messages. The IMSI and NSAPI, which allow unique association of the message with a PDP context, are included only in the first message (Create PDP Context Request) from the controlling node to the gateway node.
Both versions of the GTP operate correctly within the respective version. The standardization requires that a Version 1 node must also support GPT Version 0, that is to say it must be backward-compatible. This is necessary in order that different node versions can interact.
However, problems occur when a mobile radio subscriber is moving in a network which includes different node versions and, in the process, moves from the coverage area of one controlling node to that of another. This change results in an RAU (Routing Area Update), in which a tunnel from the node in whose coverage area the subscriber was previously located is transferred to the node of the new coverage area. In the course of this procedure, data about the PDP context must be passed by means of GTP messages from the old node to the new node. This data requires the new node to make contact with the gateway node and to switch the GTP tunnel, so that the service can be continued without any interruption for the subscriber. If all three nodes which are involved in the switching of the tunnel are to the same GTP version, there are no problems in the switching process. Even if two of them are Version 0 nodes and the third is a Version 1 node, there are no problems since all the messages interchanged between the nodes must be GTP Version 0 messages. However, if two of the nodes are of the Version 1 type and the third is of the Version 0 type, the fact that the two nodes of the Version 1 type communicate with one another using Version 1 messages and communicate with that in the third node using Version 0 messages leads to difficulties. Three situations can be distinguished.
1. The mobile radio subscriber moves from a first controlling node of the Version 0 type to a second controlling node of the Version 1 type. In this situation, GTP Version 0 must be used for the first controlling node to communicate with the second and with the gateway node; Version 1 is used for the communication between the gateway node and the second controlling node. When setting up the tunnel, the gateway node allocates a flow label, which is used by the first controlling node to identify messages associated with that tunnel. When the two controlling nodes make contact, in order to prepare for the transfer of the tunnel, they communicate using Version 0, and the first controlling node supplies the second with the flow label which was originally allocated to the tunnel by the gateway node. In order to receive necessary context data for the tunnel from the gateway node, the second controlling node would have to be able to send a message to the gateway node using this flow label. However, the second controlling node and the gateway node communicate using Version 1, which does not allow the transmission of flow labels. A Version 1 TEID could admittedly be transmitted instead of the flow label, however, no such TEID is defined in the gateway node for the tunnel. The gateway node can therefore not allocate any message of the GTP Version 1 type to the existing channel. Since the “Update PDP Context Request” message includes neither IMSI nor NSAPI, the gateway node is also then unable to find the context, if it ignores the TEID.
2. The mobile radio subscriber moves from the first controlling node of the Version 1 type to a controlling node of the Version 0 type. In this situation, GTP Version 1 has been used for the communication between the first controlling node and the gateway node in the course of setting up the tunnel, that is to say, although a TEID has been defined for the tunnel, no flow label has been defined GTP Version 0 must be used for the communication between the two controlling nodes, but this allows only flow labels. There is no way to transmit the TEID to the second node and, even if such a way were to exist, it could not be processed. It is therefore impossible for the second controlling node to find the flow labels by means of which it could request the required context data from the gateway node.
3. The mobile radio subscriber moves from a controlling node of the Version 1 type to another of the same version, although the gateway node is operating on Version 0. In this situation, the controlling nodes communicate with one another using Version 1, but communicate with the gateway node using Version 0. The gateway node thus allocates a flow label when setting up a tunnel, but this cannot be transmitted from the first node to the second node so that it also cannot check the context information from the gateway node.